| 1) Drop IPv6 Undetectable protocol/port (May be an intrinsic FW feature.) - IPv6 allows an unlimited number of extension headers to be applied to a packet. A FW may not be able to locate the layer 4 protocol and port values if too many extension headers exhaust its resources. As a minimum, a FW must be able to drop any packet for which it cannot identify the layer 4 protocol and ports (if applicable). The security policy would be subverted if these packets were allowed to pass through a FW. If the FW cannot traverse through extension headers at all, it must drop packets using any extension header. This measure will disable a large amount of IPv6’s functionality and should only be used if the Primary guidance cannot be implemented.
2) Drop IPv6 Type 0 Routing Header - The IPv6 Type 0 Routing Header (extension header) is functionally equivalent to the IPv4 loose source routing header option, which is typically blocked for security reasons. The Type 0 Routing Header is dangerous because it allows attackers to spoof source addresses and get traffic in response (rather than to the real owner of the address). Secondly, a packet with an allowed destination address could be sent through a FW only to bounce to a different (disallowed) node once inside using the Routing Header functionality. If the Type 0 Routing Header must be used, it must be used in conjunction with either the IPSec AH or the IPSec Encapsulation Security Payload (ESP) headers. If the FW cannot distinguish the type field of a routing header, it should be configured to drop all routing headers. Note that Mobile IP is disabled without the Type 2 Routing Header. Although deprecated by a recent RFC, there may be existing implementations that still recognize this header.
3) Drop Undefined IPv6 Header Extensions/Protocol Values (May be an intrinsic FW feature.) - Undefined IPv6 header extensions means that the Next Header type is not registered with Internet Assigned Numbers Authority (IANA). The header extension is the same as the protocol value, and should be dropped. Drop all undefined extension headers/protocol values.
4) Drop at least one fragment of any inbound fragmented packet for which the complete data set for filtering to include protocol/port values cannot be determined.(May be an intrinsic FW feature) - A FW must be able to properly enforce its filtering policy upon fragmented packets. This requires that the FW be able to find the complete set of header data including extension headers and the upper layer protocol/port values. It also requires that the packet not be susceptible to fragment overlap attacks. Fragment overlaps are a more serious problem in IPv6 than in IPv4 because the presence of extension headers can push the upper layer protocol/port information outward (toward packet boundaries) making it much harder to protect. How a FW achieves these requirements is not important as long as both aspects are met. The wording “drop at least one fragment” used in the actions below is a statement of the bare minimum action to secure a packet, and is chosen to allow FW venders flexibility in achieving it. Refer to Firewall Design Considerations for IPv6 section 3.6 for extensive detail on this topic. https://www.us.army.mil/suite/doc/10209656
5) Drop all inbound IPv6 packets containing more than one Fragmentation Header within an IP header chain. (May be an intrinsic FW feature) - Nested fragmentation is an unnecessary and unwanted IPv6 condition that is not forbidden by the specifications. It occurs when an IP header chain contains more than one Fragmentation Header implying that a fragment has been fragmented. In the specification, the phrase “IP header chain” rather than “packet” is used, because a tunneled packet has more than one IP header chain and each chain can have a Fragment Header (this case is not nested fragmentation). Nested fragmentation is a new phenomenon with IPv6. It is not possible in IPv4, because the fragmentation fields are part of the main header and are modified in the event of a secondary fragmentation event. Nested fragmentation in IPv6 should be dropped by FWs since internal nodes that process the fragmentation may or may not be equipped to handle this unexpected case. These nodes may crash or behave in some unpredictable manner. |
